Cooperative driving and collision avoidance by distributed receding horizon control

ABSTRACT

Distributed control of vehicles with coordinating cars that implement a cooperative control method, and non-coordinating cars that are presumed to follow predictable dynamics. A cooperative control method can combine distributed receding horizon control, for optimization-based path planning and feedback, with higher level logic, to ensure that implemented plans are collision free. The cooperative method can be completely distributed with partially synchronous execution, and can afford dedicated time for communication and computation, features that are prerequisites for implementation on real freeways. The method can test for conflicts and can calculate optimized trajectories by adjusting parameters in terminal state constraints of an optimal control problem.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims the benefit of priorityunder 35 U.S.C. § 120 from U.S. application Ser. No. 13/486,598, filedJun. 1, 2012.

BACKGROUND

This disclosure relates to distributed receding horizon control (DRHC)and collision avoidance of coordinating and non-coordinating vehicles.

The “background” description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Work describedherein, to the extent it is described in this background section, aswell as aspects of the description which may not otherwise qualify asprior art at the time of filing, are neither expressly or impliedlyadmitted as prior art.

Aspects of this disclosure relate to the teachings of the followingreferences, which are referred to throughout:

-   [1] L. D. Baskar, B. De Schutter, J. Hellendoorn, and Z. Papp.    Traffic control and intelligent vehicle highway systems: a survey.    Intelligent Transport Systems, IET, 5(1):38-52, March 2011.-   [2] O. Becker. Tutorial—2D Rotated Rectangles Collision    Detection, 2003. url: www (dot) ragestorm (dot) net/tutorial?id=22.-   [3] R. Bishop. Intelligent vehicle applications worldwide. IEEE    Transactions on Intelligent Systems and their Applications,    15(1):78-81, January.-   [4] W. B. Dunbar and D. Caveney. Distributed receding horizon    control of vehicle platoons: Stability and string stability. IEEE    Trans. on Automatic Control, In press, DOI 10.1109/TAC.2011.2159651,    June 2011.-   [5] W. B. Dunbar and R. M. Murray. Distributed receding horizon    control for multi-vehicle formation stabilization. Automatica,    42(4):549-558, 2006.-   [6] P. Falcone, F. Borrelli, E. H. Tseng, J. Asgari, and H. Davor.    Low complexity MPC schemes for integrated vehicle dynamics control    problems. In Proceedings of the 9th International Symposium on    Advanced Vehicle Control (AVEC '08), pages 875-880, 2008.-   [7] R. A. Ferlis. The dream of an automated highway. Public Roads,    71(1), Pub. No. FHWA-HRT-07-005 2007.-   [8] E. Franco, L. Magni, T. Parisini, M. M. Polycarpou, and D. M.    Raimondo. Cooperative constrained control of distributed agents with    nonlinear dynamics and delayed information exchange: A stabilizing    receding-horizon approach. IEEE Trans. on Automatic Control,    53(1):324-338, 2008.-   [9] P. Toannou, editor. Automated Highway Systems. Plenum Press, New    York, 1997.-   [10] T. Keviczky, F. Borrelli, and G. J. Balas. Decentralized    receding horizon control for large scale dynamically decoupled    systems. Automatica, 42(12):2105-2115, December 2006.-   [11] N. J. Kohut, J. K. Hedrick, and F. Borrelli. Integrating    traffic data and model predictive control to improve fuel economy.    In Proceeding of 12th IFAC Symposium on Control in Transportation    Systems, pages 2806-2813, 2009.-   [12] Y. Kuwata, A. G. Richards, T. Schouwenaars, and J. P. How.    Distributed robust receding horizon control for multi-vehicle    guidance. IEEE Transactions on Control Systems Technology, 15(4),    July 2007.-   [13] D. Q. Mayne, J. B. Rawlings, C. V. Rao, and P. O. M. Scokaert.    Contrained model predictive control: Stability and optimality.    Automatica, 36:789-814, 2000.-   [14] M. B. Milam, K. Mushambi, and R. M. Murray. A new computational    approach to real-time trajectory generation for constrained    mechanical systems. In Proceedings of the Conference on Decision and    Control, 2000.-   [15] Intelligent Transportation Systems (ITS) Joint Program Office.    Intellidrive safety workshop. U.S. Department of Transportation,    Research and Innovative Technology Administration,    http://www.its.dot.gov/, July 2010.-   [16] N. Petit, M. B. Milam, and R. M. Murray. Inversion based    trajectory optimization. In Proceedings of the IFAC Symposium on    Nonlinear Control Systems Design (NOLCOS), 2001.-   [17] A. Richards and J. How. Robust model predictive control with    imperfect information. In Proceedings of the American Control    Conference, 2005.-   [18] A. G. Richards, J. P. How, T. Schouwenaars, and E. Feron.    Spacecraft trajectory planning with avoidance constraints using    mixed-integer linear programming. AIAA Journal of Guidance Control    and Dynamics, 25(4):755-764, 2002.-   [19] B. Saerens, M. Diehl, J. Swevers, and E. Van den Bulck. Model    predictive control of automotive powertrains—first experimental    results. In Proceedings of the 47th IEEE Conference on Decision and    Control, pages 5692-5697, 2008.-   [20] J. D. Schwartz and M. B. Milam. On-line path planning for an    autonomous vehicle in an obstacle filled environment. In Proceedings    of the IEEE Conference on Decision and Control, pages 2806-2813,    2008.-   [21] R. Sengupta, S. Rezaei, S. E. Shladover, D. Cody, S. Dickey,    and H. Krishnan. Cooperative collision warning systems: Concept    definition and experimental implementation. Journal of Intelligent    Transportation Systems, 11(3):143-155, 2007.-   [22] S. E. Shladover. PATH at 20—History and major milestones. IEEE    Transactions on Intelligent Transportation Systems, 8(4):584-592,    December 2007.-   [23] Technical showcase. Raytheon: Infrastructure BSM generator for    V2V. In 18th World Congress on Intelligent Transport Systems,    October 2011.-   [24] A. Vahidi and A. Eskandarian. Research advances in intelligent    collision avoidance and adaptive cruise control. Intelligent    Transportation Systems, IEEE Transactions on, 4(3):143-153,    September 2003.-   [25] Y. Wang and S. Boyd. Fast model predictive control using online    optimization. IEEE Transactions on Control Systems Technology,    18(2):267-278, 2010.

SUMMARY

An aspect of this disclosure considers the problem of distributedcontrol of vehicles with coordinating cars that implement a cooperativecontrol method, and non-coordinating cars that are presumed to followpredictable dynamics. The cooperative control method presented combinesdistributed receding horizon control, for optimization-based pathplanning and feedback, with higher level logic, to ensure thatimplemented plans are collision free. The cooperative method iscompletely distributed with partially synchronous execution, and affordsdedicated time for communication and computation, features that areprerequisites for implementation on real freeways. Merging simulationswith coordinating and non-coordinating cars demonstrate the viability ofthe method, including a detailed six-car merging scenario, and alarger-scale merge that models the Japanese Tomei Expressway roadgeometry and traffic flow conditions. The look-ahead feature of recedinghorizon control is exploited for resolving conflicts (future collisions)before they occur, and for negotiating aspects of inter-vehicle mergingcoordination, even before the closed-loop response is initiated. Suchcapabilities are not possible by any other method that simultaneouslyprovides low-level control.

An embodiment of controller for a first coordinating vehicle can includea communication terminal configured to receive trajectory messages froma plurality of second coordinating vehicles in a communication range.The trajectory messages can include vehicle trajectory information for apredetermined update interval.

The controller can include a computer processor configured to executeinstructions stored on a non-transitory memory. The instructions caninclude calculating an assumed trajectory for the first coordinatingvehicle by solving an optimal control problem, detecting a conflictbased on the received trajectory information and the calculated assumedtrajectory, and when a conflict is detected, adjusting terminal stateconstraints in the optimal control problem and calculating, with theadjusted constraints in the optimal control problem, an optimizedtrajectory for the first coordinating vehicle such that the detectedconflict is resolved. The assumed trajectory for the first coordinatingvehicle can be calculated by solving the optimization control problemwith terminal constraints modified by a high-level maneuver plan. Theoptimal control problem can include cost terms including a movesuppression (MS) term indicating an amount that the optimized trajectorymay deviate from the assumed trajectory.

The controller can be further configured such that the conflict isdetected by determining, based on the received trajectory informationand the calculated assumed trajectory, whether a first avoidanceboundary of the first coordinating vehicle and a second avoidanceboundary of any one of the second coordinating vehicles intersect duringthe update interval.

The terminal state constraints in the optimal control problem caninclude a velocity term and a vehicle spacing term. When a conflict isdetected, the processor can adjust the velocity term and/or the vehiclespacing term in the optimal control problem such that the detectedconflict is resolved.

During each of successive update intervals, the computer processor canrecursively detect conflicts between the first coordinating vehicle andeach of the second coordinating vehicles that will occur during theupdate interval and calculate the optimized trajectory for each of therecursively detected conflicts. The assumed trajectory for the firstcoordinating vehicle in a current update interval can be initially setto the calculated optimized trajectory from an immediately precedingupdate interval. The assumed trajectory for the first coordinatingvehicle in a current update interval can be initially set, in theabsence of a high-level maneuver plan, by extrapolating the optimizedtrajectory from an immediately preceding update interval.

During each of the successive update intervals, the controller cancalculate the optimized trajectory for the detected conflict with theearliest loss-of-separation that requires action by the firstcoordinating vehicle.

During each of the successive update intervals, the communicationterminal can be configured to transmit the optimized trajectory to thesecond coordinating vehicles and receive updated trajectory messagesfrom the second coordinating vehicles.

The controller can be further configured to classify the detectedconflict based on a predetermined rule set and adjust the terminal stateconstraints based on the detected conflict classification. The conflictclassification can be based on a position of the first coordinatingvehicle relative to a conflicting vehicle, of the second coordinatingvehicles, which is determined to be in conflict with the firstcoordinating vehicle. When a conflict is detected, the MS term can beset such that the amount from which the optimized trajectory may deviatefrom the assumed trajectory is infinite.

The controller can include a detection unit configured to detect aposition and speed information for a non-coordinating vehicle within apredetermined detection range. The processor can determine trajectoryinformation for the non-coordinating vehicle based on the detectedposition and speed information, and the processor can detect a conflictbetween the first coordinating vehicle and the non-coordinating vehiclebased on the determined trajectory information and the assumedtrajectory. The processor can be configured to set a third avoidanceboundary for the non-coordinating vehicle, the third avoidance boundarybeing smaller in size than the first and second avoidance boundaries.

A method for controlling a first coordinating vehicle can comprisereceiving trajectory messages from a plurality of second coordinatingvehicles in a communication range, the trajectory messages includingvehicle trajectory information for a predetermined update interval;calculating an assumed trajectory for the first coordinating vehicle bysolving an optimal control problem; detecting a conflict based on thereceived trajectory information and the calculated assumed trajectory;and when a conflict is detected, adjusting terminal state constraints inthe optimal control problem and calculating, with the adjustedconstraints in the optimal control problem, an optimized trajectory forthe first coordinating vehicle such that the detected conflict isresolved.

A vehicle coordination system can comprise a plurality of coordinatingvehicles, each vehicle (i=1, 2, 3, . . . , N) having a controller. Thecontroller can include a communication terminal configured to receivetrajectory messages from each vehicle, of the plurality of coordinatingvehicles, in a communication range. The trajectory messages can includevehicle trajectory information for a predetermined update interval. Thecontroller can include a computer processor configured to executeinstructions stored on a non-transitory memory. The instructions caninclude calculating an assumed trajectory by solving an optimal controlproblem; for each received trajectory message, detecting a conflict witha corresponding vehicle based on the received trajectory information andthe calculated assumed trajectory; and when a conflict is detected,adjusting terminal state constraints in the optimal control problem andcalculating, with the adjusted constraints in the optimal controlproblem, an optimized trajectory for the first coordinating vehicle suchthat the detected conflict is resolved.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

A more complete appreciation of the disclosed embodiments and many ofthe attendant advantages thereof will be readily obtained as the samebecomes better understood by reference to the following detaileddescription when considered in connection with the accompanyingdrawings, wherein:

FIG. 1 is a conceptual description of the four tasks executed duringeach δ-second update period [t_(k), t_(k+1)], with update times t_(k)and t_(k+1)=t_(k)+δ;

FIG. 2 is a graphical representation of a car at some instant of timewith global configuration positions (x, y) and (ψ, v);

FIG. 3A is a computed (solid outline) and assumed (dashed outline)configuration for a car at some instant of time, in an arbitrary roadgeometry;

FIG. 3B is a close-up of two vehicle configurations in the relativeframe in which the assumed position and heading are zero, where thevariables in the figure (Δx, Δy, Aψ) are defined in equation (8);

FIGS. 4A-4F are position space (y, x) snapshots of a 6 car simulation atvarying times, where the black boundary for all cars (coordinating andnon-coordinating) represents the avoidance boundaries parameterized by(Δ_(x), Δ_(y)), and the added white boundary around the coordinatingcars represents the added margin afforded by move suppression parameters(ε_(x), ε_(y)), and overlapping white boundaries are conflicts, andboundaries change color to red for one conflict and to yellow for twosimultaneous conflicts, in which:

FIG. 4A is a 0 sec snapshot that shows the cars at steady-state, beforethe car 1 lane change and consequent conflicts;

FIG. 4B is a 3.4 sec snapshot that shows cars 2 and 3 in conflict witheach other;

FIG. 4C is a 4.7 sec snapshot that shows cars 1 and 3 are in conflictwith car 2, where car 2 has two conflicts, and so has a yellow boundary;

FIG. 4D is a 5 sec snapshot that shows cars 1 and 2 with two conflictseach, and car 3 with one conflict;

FIG. 4E is a 8.7 sec snapshot that shows that the conflict between car 1and car −1 is no longer active, resulting in a color change for theboundary of car 1, where car 2 still has two conflicts, one with car 1and one with car 3; and

FIG. 4F is an end time (30 sec) snapshot that shows that all conflictsare resolved;

FIG. 5 is a graphical plot of speed v_(i) for each of four coordinatingcars with respect to time t, where Cars 3 and 4 slow initially due tothe conflicts with cars 2 and 3, respectively, and the more dramaticchain of speed reductions follows the merging of car 1 behind car −1,with speed reductions required to create enough space to resolve allin-lane conflicts;

FIG. 6 is a series of five-second snapshots of a merging scenario on theTomei Expressway in Japan;

FIG. 7 is a schematic of a processing system according to embodiments ofthis disclosure;

FIG. 8 is a flowchart of algorithms implementing aspects of thisdisclosure; and

FIG. 9 is a cooperative driving software framework for a coordinatingvehicle, where interfaces between different layers of the framework arenumbered and described in Table 1, while communication interfaces arelettered.

DETAILED DESCRIPTION 1. Introduction

An issue facing the developed world is that much of the infrastructurefor transportation will not scale with near-future populations [7], [9].To bypass the cost of new road infrastructure, there is substantialeffort to develop automation-based solutions in which control algorithmsperform human tasks to yield greater throughput within existinginfrastructure [1], [22]. In the context of freeway driving, suchmethods incorporate hardware/software and control logic into existingvehicles on freeways already in use. There are many challenges to anyapproach that automates some aspect of highway driving. The obviouschallenge is ensuring vehicles do not collide with each other or roadwaybarriers. Another challenge is to ensure that adaptation to changingfreeway conditions occurs seamlessly and robustly, while maintainingthroughput that exceeds that of human driving under (ideally) allconditions.

This disclosure considers the problem of automated freeway driving underthe specific scenario of merging. Within this scenario, challengesinclude the spatial and time constraints associated with merging whencooperative and non-cooperative vehicles are in the merging lane.Related work has proposed and tested cooperative collision warning (CCW)systems that provide situation awareness and warnings to drivers [21].There are also review papers that consider trends in collisionavoidance/warning systems and automation of vehicle control tasks [3],[24]. Adaptive cruise control alone cannot handle time constraints ingeneral, which will be required within one or more layers of logic thatautomate freeway driving under general conditions, including freewaymerging. Thus, there is a need to merge lower-level control withhigher-level task management schemes in freeway automation methods.

This disclosure presents an automation method with receding horizoncontrol as the lower-level control method, combined with a higher-levellogic for management of lane changing and collision avoidance. A newimplementation of distributed receding horizon control is utilized inwhich each cooperative vehicle is assigned its own optimal controlproblem, optimizes only for its own control at each update, andtransmits and receives information with vehicles in communication range.The local optimal control problems are entirely decoupled; thus,feasibility of each optimization problem does not depend on solutions oreven communication with other vehicles. Cooperation is achieved byadjusting constraints and parameters in each optimal control problem,based on a separate higher-level logic that tests for collisions andmanages parameter/constraint adjustments when conflicts arise. Thisapproach is in contrast with other receding-horizon approaches wherecooperation between subsystems is incorporated directly in the optimalcontrol problem by including explicit coupling terms in the costfunction or constraints [5], [10]. Another advantage of the method isthat the implemented optimization problem is a quadratic programmingproblem, which can be solved robustly and efficiently.

As a non-limiting example, this disclosure presents a specific freewayscenario that is a left-lane merger of a car onto a freeway, a commonscenario on Japanese freeways. Cars are treated as either “coordinating”or “non-coordinating.” By definition, coordinating cars employ thecontrol approach presented herein. Non-coordinating cars are not beingregulated, and are viewed as moving obstacles by each coordinating car.To simplify the problem, the short-term future plan of non-coordinatingcars is assumed to be predictable without error by each coordinatingcar. Knowledge of the current state (e.g., position, heading, velocity)of non-coordinating cars is consistent with recent advances by industryand government that advances vehicle-2-vehicle (V2V) technology. Suchtechnology could provide knowledge of non-coordinating cars by each carbroadcasting its state information (USDOT, [15]), or by road-sidedevices that estimate and broadcast the state of such cars (Raytheon,[23]). Thus, it is conceivable that in future intelligent freeways thestate of non-coordinating is available, from which a short-term plancould be estimated. In the approach presented here, coordinating carsexchange future plans, and modify them as necessary to ensure collisionavoidance and acceptable performance. The term “conflict” refers to whenthe plan of any car results in a loss of separation, which means thatthe avoidance boundaries of the two cars intersect, now or at some timewithin the planning horizon. If loss of separation does not occur, thenactual collision cannot occur. Thus, a conflict-free plan is sufficientas a collision-free plan.

The approach presented herein is comprised of the following features: 1)distributed, partially synchronous execution, 2) optimization-basedmaneuvering and feedback control by receding horizon control, and 3)logic-based conflict avoidance. A high-level overview of each of thesethree aspects is now given.

Distributed Partially-Synchronous Execution

Each coordinating car must make decisions locally, exchanging planinformation with cars (“neighbors”) in range of communication. Eachupdate window is synchronized (via a global clock keeping with GPS),while communication exchanges can be asynchronous provided the maximumdelay is bounded and less than the update period. Computations (byoptimization) are also completely distributed and asynchronous.

FIG. 9 illustrates a non-limiting exemplary framework for cooperativedriving that integrates event-based group coordination logic, periodic(optimization-based) path planning, digital maps, collision avoidance,and communications. The interfaces between various levels of theframework and external entities are summarized in Table 2. At the coreof the framework is a four-task strategy for path planning. AlthoughDRHC based path planning is proposed within this strategy, optimizationis not a prerequisite. However, integration through online optimizationguarantees constraints are satisfied and maximum (as defined by the costfunction) performance is achieved.

TABLE 1 Interface Functionality Example 1. Road Network Level to HighRoute plan to event-based I am a cooperative vehicle traveling on thehighway and approaching Level scenarios an interchange. I will nowlisten for vehicles merging from a ramp. 2. High Level to Middle LevelEvent-based maneuver plans to I have negotiated a lane-change to beginin 2.1 secs. I will speed up (periodic) nominal assumed to 25 m/s at 0.5m/s/s to meet a gap in the traffic available in 6.2 secs. trajectories3. Middle Level to Low Level Conflict-free path plans to (body- Iresolved a conflict with a trajectory from a neighboring vehicle andfixed) throttle, brake, and steering produced a global longitudinal andlateral acceleration profiles to commands realize the conflict-freetrajectory. 4. Low Level to Physical Throttle, brake, and steering Ineed a throttle angle of 10.2 deg. This requires a PWM signal ofActuators commands to CAN messages 12.3%. A. Event-based Messagescontaining quantities I am a cooperative vehicle traveling on thehighway. Here are gaps Communications necessary to coordinate the aroundme in which vehicles can lane change. maneuvers of multiple vehicles B.Assumed Trajectory Messages containing (nominal) I am a cooperativevehicle. Here are my (global) position, velocity, Communications pathplanning solutions of other and acceleration profiles for the next 5seconds. cooperative vehicles Road Geometry (Digital Map) Upcoming roadgeometry to Here are GPS waypoints defining the three lanes of upcomingroad nominal assumed trajectories geometry in the next 300 meters.updates Abort Maneuver Plan Conflict detections to negotiated I have anunforeseen conflict with another vehicle this is unable to be maneuverplans resolved without abandoning our negotiated maneuver plan.

Referring to FIG. 9, the common order of execution of tasks for each carover the common update period (0.5 seconds here, without loss ofgenerality) includes:

Task 1: Generate a nominal “assumed trajectory” for the next planninghorizon, which may involve solving an optimization problem. For carsthat are merging into a lane, for example, optimization is used tocompute the initial lane-change maneuver.

Task 2: Exchange (transmit and receive) assumed trajectories with eachneighbor.

Task 3: Check assumed trajectories (self against neighbors) forconflicts, and resolve any conflicts as necessary. Conflict “types”determine the resolution assignment, as detailed in this work. Computinga conflict-resolving maneuver involves solving an optimization problem.

Task 4: Solve an optimization problem to generate the next implementedmaneuver, if not already done in tasks 1 or 3. This is required wheninitial maneuvers are simple to compute (i.e., no optimization requiredin task 1) and such maneuvers do not result in a conflict (nooptimization required in task 3).

FIG. 1 shows, at a conceptual level, each of the four tasks sequentiallyexecuted during each receding horizon update period. An optimizationproblem will be solved one or two times during each update period, foreach coordinating car. During each update period, the purpose of thefour tasks is to provide a conflict-free receding horizon trajectorythat will be implemented during the next update period. Assume that allcars have synchronized update times t_(k), k∈┐, but the execution oftasks within each update period need not be synchronized. The timingrequirement is that all four tasks are completed within each updateperiod for every car. Only the inter-vehicle communication task 2requires coordination between vehicles.

The four-task strategy presented here separates the optimization problemfrom the handling of collision avoidance. Handling collision avoidanceconstraints directly in the optimization problem generally makes theproblem non-convex and/or introduces decision variables ([12], [18])that, when added to the computed trajectory variable set, candramatically increase computation time. The solution to such non-convexproblems are also locally optimal, which has computational implications(e.g., solutions depend largely on the chosen warm-start solution). Tobypass these computational issues, avoidance constraints are notincluded in the present optimization problem. Instead, task 3 logictests for conflicts and adjusts parameters in the terminal stateconstraints in the optimization problem to resolve a detected conflict.This is a distinct advantage the present approach compared to approachesin the literature.

Optimization-Based Maneuvering

Receding horizon control is used to compute the maneuver of each car. Inreceding horizon control the current control action is determined bysolving a finite-horizon optimal control problem within each samplingperiod [13]. Each optimization yields an open-loop control trajectoryand the initial portion of the trajectory is applied to the system untilthe next sampling instant. In this disclosure, the planned maneuver isshort-term (5 seconds) and incorporates the dynamics of the car,smoothness conditions between maneuver updates, a move suppressionconstraint, and minimizes a cost function. In practice, low-level(inner-loop) controllers may be used to stabilize cars along thecomputed maneuver. Avoidance constraints (between cars, and between carand road boundary) are not included in the optimization problem, but areincorporated in distributed logic executed by each car in parallel,between optimization updates.

The automotive industry is embracing receding horizon control researchfor powertrain [19] and vehicle stability [6] applications. Furthermore,this research is being applied to path planning applications forautonomous driving [20] and eco-driving [11]. The convergence ofadvanced global positioning technologies, prototype V2V communication,and increased onboard computation capabilities has allowed academia andindustry to explore the possibilities of cooperative control betweencars. Distributed receding horizon control enables cooperative controlby enforcing constraints on allowable vehicle motion and sharingpredicted paths between vehicles. Global positioning further enablescooperative control through the existence of a common global clock andinertial coordinate frame.

Each coordinating vehicle uses an assumed trajectory (denoted{circumflex over (M)}), which is computed in task 1. The assumedtrajectory is made available to all neighboring cars in task 2, thenchecked for conflicts using logic in task 3. When conflicts aredetected, the logic “types” the conflict, and then resolves the conflictaccording to its type. Conflict types are distinguished by the positionof each vehicle relative to the conflicting vehicle (e.g., behind,ahead, on left and merging right, etc.). The notation {circumflex over(M)}_(i) is used to denote the assumed trajectory specific to car i. Themove suppression constraint in the optimization problem is used toensure that newly optimized trajectories remain within set bounds(termed “move suppression margins”) of {circumflex over (M)}. The logicthat ensures {circumflex over (M)} is conflict-free incorporates themove suppression margins, to ultimately ensure that implementedmaneuvers are conflict free. This is described in greater detail inSection II.

Section II defines the optimal control problem (OCP) solved locally foreach car, and includes calculations for parameters in each OCP that aretuned by the four-task execution logic. The OCP is time-discretized andsolved numerically by methods detailed in Section III. The four-tasklogic is presented in Section IV, which includes the method of typingdifferent conflicts that can occur between vehicles. To demonstrate thelogic in cooperative freeway merging, a non-limiting example of asix-car merging scenario is presented in Section V, followed by alarger-scale example in Section VI that models a representative merge onthe Japanese Tomei Expressway. Section VII discusses hardwarecontrollers and exemplary algorithms. Section VIII discusses conclusionsand extensions.

II. Optimal Control Problem for Individual Coordinating Vehicles

This section defines the continuous time 2-dimensional optimal controlproblem (OCP) for each individual coordinating vehicle. In futuresections, the subscript i=1, 2, . . . n, on each variable denotes thecoordinating car number. Since the OCP is decoupled for each car, thei-subscript notation is not used in this section. Based on a unicyclemodel, each car has state variables (x(t), y(t), {dot over (x)}(t), {dotover (y)}(t))∈|⁴ and heading/speed control inputs (ψ(t), v(t))∈|² at anytime t∃0, with coordinate frame defined in FIG. 2. The continuous timemodel of the dynamics is:{dot over (x)}=v cos(ψ), {dot over (y)}=v sin(ψ).  (1)

The control problem requires constraints on the states and inputs, and acost penalty is used to smooth the time rate-of-change of the controlinputs. Using the concept of differential flatness [16], there is aone-to-one map from the variables (x, {dot over (x)}, {umlaut over (x)},y, {dot over (y)}, ÿ) to the variables (x, y, ψ, v, {dot over (ψ)}, {dotover (v)}) using these substitutions:

$\begin{matrix}{{v = \sqrt{{\overset{.}{x}}^{2} + {\overset{.}{y}}^{2}}},{\overset{.}{v} = \frac{{\overset{.}{x}\overset{¨}{x}} + {\overset{.}{y}\overset{¨}{y}}}{\sqrt{{\overset{.}{x}}^{2} + {\overset{.}{y}}^{2}}}},{\psi = {\arctan\left( {\overset{.}{y}/\overset{.}{x}} \right)}},{\overset{.}{\psi} = \frac{{\overset{.}{x}\overset{¨}{y}} - {\overset{.}{y}\overset{¨}{x}}}{{\overset{.}{x}}^{2} + {\overset{.}{y}}^{2}}}} & (2)\end{matrix}$

Using these substitutions in the OCP, the dynamics are implicitly (andexactly) satisfied, and the dynamic equations (1) need not be includedas constraints in the OCP. Since v>0 in the described multi-carscenarios, {dot over (x)}>0 and/or {dot over (y)}>0; thus, there are nosingularity problems in computing the substituted variables (2). Whilethe OCP is defined in terms of the (x, {dot over (x)}, {umlaut over(x)}, y, {dot over (y)}, ÿ)) variables, the “assumed trajectories”communicated (in task 2) and tested for conflicts (in task 3) are basedon the variables (x, y, ψ, v) When conversion to either variable set isrequired, (2) or its inverse map (which follows trivially from (1) andits time derivative) is used.

Notation used to define the OCP is assembled into Table 2.

TABLE 2 Variable Meaning T Receding horizon planning period (5 sec) δReceding horizon update period (0.5 sec) t_(k) Receding horizon updatetime (sec), t_(k) = k * δ, k = 0, 1, . . . x^(c)(•; t_(k)):[t_(k),t_(k) + T] →  

  Trajectory to be optimized (likewise for y and time derivatives)x^(ref)(•; t_(k)):[t_(k), t_(k) + T] →  

  Reference trajectory in the cost function (likewise for y and timederivatives) x^(des) ∈  

  Desired end state x^(c)(t_(k) + T; t_(k)) = x^(des) (likewise for yand time derivatives) {circumflex over (x)}(•; t_(k)):[t_(k), t_(k) + T]→  

  Assumed trajectory, version n = 1, 2 (likewise for y, ψ, v)  

 (t_(k)) The communicated set of assumed trajectories {{circumflex over(x)}, ŷ, {circumflex over (ψ)}, {circumflex over (v)}}.Notation x(t) denotes the actual x-position of car at any time t,whereas x^(c)(t; t_(k)) is the computed position defined only on thetime interval [t_(k), t_(k)+T]. By the receding horizon implementation,these trajectories coincide over the update period:x(t)=x ^(c)(t;t _(k)),t∈[t _(k) ,t _(k+1)].  (3)

In reality, of course, inner-loop control makes these trajectories closebut not exactly equal. For the planning period [t_(k), t_(k)+T], the OCPhas the following data: the initial valuesX _(I)(t _(k))=(x(t _(k)),{dot over (x)}(t _(k)),{umlaut over (x)}(t_(k)),y(t _(k)),{dot over (y)}(t _(k)),{umlaut over (y)}(t _(k))),the desired end valuesX _(F)(t _(k) +T)=(x ^(des) ,{dot over (x)} ^(des) ,y ^(des) ,{dot over(y)} ^(des)),and the reference and assumed trajectories. The continuous time OCPusing the flat parameterization is:

min ( x c , y c , x . c ⁢ , y . c , x ¨ c , y ¨ c ) ⁢ ∫ t k t k + T ⁢ { w x⁡[ x c ⁡ ( s ; t k ) ⁢ ⁢ … ⁢ ⁢ x ref ⁡ ( s ; t k ) ] 2 + w y ⁡ [ y c ⁡ ( s ; t k) - y ref ⁡ ( s ; t k ) ] 2 + w xd ⁡ [ x . c ⁡ ( s ; t k ) - x . ref ⁡ ( s ;t k ) ] 2 + w xd ⁡ [ y . c ⁡ ( s ; t k ) ⁢ - y . ref ⁡ ( s ; t k ) ] 2 ⁢ ⁢ wxdd ⁡ [ x ¨ c ⁡ ( s ; t k ) ] 2 + w ydd ⁡ [ y ¨ c ⁡ ( s ; t k ) ] 2 } ⁢ ds (4 ) s . t . ⁢ γ ms ⁢ G ⁡ ( x c ⁡ ( t ; t k ) , y c ⁡ ( t ; t k ) , ⁢ ( t k ) )≤ 0 ⁢ ∈ 2 , ⁢ t ⁢ ∈ [ t k , t k + T ] ( 5 ) ( x c ⁡ ( t k ; t k ) , x . c ⁡ (t k ; t k ) , x ¨ c ⁡ ( t k ; t k ) , y c ⁡ ( t k ; t k ) , y . c ⁡ ( t k ;t k ) , y ¨ c ⁡ ( t k ; t k ) ) = X 1 ⁡ ( t k ) ( 6 ) ( x c ⁡ ( t k + T ; tk ) , x . c ⁡ ( t k + T ; t k ) , y c ⁡ ( t k + T ; t k ) , y . c ⁡ ( t k +T ; t k ) ) = X F ⁡ ( t k + T ) ( 7 )

The weights are chosen (w_(x), w_(y), w_(x), w_(yd), w_(xdd), w_(ydd))>0in (4). Reference trajectories enter only in the cost function (4), andassumed trajectories enter only in the constraints (5). The function Gin (5) defines two “move suppression constraints” and γms=1 if movesuppression is active, and 0 if it is not. The move suppressionconstraints G=(g1, g2) are defined asg ₁

{x ^(c)(t;t _(k))−{circumflex over (x)}(t;t _(k))} cos({circumflex over(ψ)}(t;t _(k)))+{y ^(c)(t;t _(k))−{circumflex over (y)}(t;t _(k))}sin({circumflex over (ψ)}(t;t _(k)))|−ϵ_(x),g ₂

{y ^(c)(t;t _(k))−{circumflex over (y)}(t;t _(k))} cos({circumflex over(ψ)}(t;t _(k)))−{x ^(c)(t;t _(k))−{circumflex over (x)}(t;t _(k))}sin({circumflex over (ψ)}(t;t _(k)))|−ϵ_(y),with ϵ_(x), ϵ_(y)>0. Activation (on vs. off) of the move suppressionconstraints is described in the four-task execution logic details inSection IV. The assumed trajectories {circumflex over (M)}(t_(k)) aredefined to start and end with the corresponding initial condition anddesired values, respectively. Consequently, due to (6)-(7), the computedand assumed trajectories are always equal at the start and the end ofeach planning horizon.

The purpose of the move suppression constraints (5) is to ensure thatthe computed maneuver remains within bounds of {circumflex over (M)}.Separately, logic (defined in Section IV-A) ensures that {circumflexover (M)} is conflict free, and incorporates the margin that defines howfar computed maneuvers can be from {circumflex over (M)} to thus ensurethat the maneuver itself is conflict free. To graphically visualize (5),define the deviation variables (Δx, Δy, Δψ) in a relative frame that istranslated by {circumflex over (x)}, ŷ and rotated by {circumflex over(ψ)}, such that the assumed car is at the origin:

$\begin{matrix}\left. \begin{matrix}{{\Delta\; x}\overset{\bigtriangleup}{=}{{\left\{ {{x^{c}\left( {t;t_{k}} \right)} - {\hat{x}\left( {t;t_{k}} \right)}} \right\}{\cos\left( {- {\hat{\psi}\left( {t;t_{k}} \right)}} \right)}} - {\left\{ {{y^{c}\left( {t;t_{k}} \right)} - {\hat{y}\left( {t;t_{k}} \right)}} \right\}{\sin\left( {- {{\hat{\psi}}_{i}\left( {t;t_{k}} \right)}} \right)}}}} \\{{\Delta\; y}\overset{\bigtriangleup}{=}{{\left\{ {{y^{c}\left( {t;t_{k}} \right)} - {\hat{y}\left( {t;t_{k}} \right)}} \right\}{\cos\left( {- {\hat{\psi}\left( {t;t_{k}} \right)}} \right)}} + {\left\{ {{x^{c}\left( {t;t_{k}} \right)} - {\hat{x}\left( {t;t_{k}} \right)}} \right\}{\sin\left( {- {{\hat{\psi}}_{i}\left( {t;t_{k}} \right)}} \right)}}}} \\{{\Delta\;\psi}\overset{\bigtriangleup}{=}{{\psi^{c}\left( {t;t_{k}} \right)} - {\hat{\psi}\left( {t;t_{k}} \right)}}}\end{matrix} \right\} & (8)\end{matrix}$Then (5) is equivalent to |Δx|≤ϵ_(x) and |Δy|≤ϵ_(y). In FIG. 3, a car'scomputed and assumed configurations are shown at some instant in time(FIG. 3A), and a close-up of these configurations in the relative frame(FIG. 3B) shows the deviation variables defined in (8).

Although the move suppression constraints (5) explicitly bound how muchΔx, Δy deviate, the heading deviation Δψ is only implicitly bounded,since a feasible solution to the OCP (in which dynamics and movesuppression are satisfied for all time over the planning horizon) limitshow big Δψ can be. Moreover, since the computed and assumed trajectoriesare always equal at the start and the end of each planning horizon, Δψ=0at the start and end of each planning horizon also.

When the move suppression constrains (5) are off, the OCP does notrequire the assumed trajectories {circumflex over (M)}(t_(k)).Constraints (5) are activated except in two cases: 1) The car iscomputing the nominal assumed trajectory in task 1 that is initiating achange in desired speed or a lane change; or, 2) The car is computing aresolution to a detected conflict in task 3. Observe that (5) are linearconstraints in the computed variables (x^(c), y^(c)).

A. Computation of Initial and Desired States

1) Task 1: Before an optimization problem is solved, the initial statesX_(I) and desired end states X_(F) must be computed. This computation isdone during task 1, the nominal update task, using the trajectoriescomputed during the previous update. Changes to X_(F) are also possiblein task 3 if a resolution is required for a coordinating car; details onthese changes are provide in Section IV. The initial states are definedsimply asX _(I)(t _(k))

(x ^(c)(t _(k) ;t _(k−1)),{dot over (x)} ^(c)(t _(k) ;t _(k−1)),{umlautover (x)} ^(c)(t _(k) ;t _(k−1)),y ^(c)(t _(k) ;t _(k−1)),{dot over (y)}^(c)(t _(k) ;t _(k−1)),ÿ ^(c)(t _(k) ;t _(k−1))).

The 4 desired end states X_(F)(t_(k)+T)=(x^(des), {dot over (x)}^(des),y^(des), {dot over (y)}^(des)) are computed as described next.

Here, and in the remainder of this disclosure, assume the highway isstraight with driving in the x-direction (ψ=0 heading). Non-straightroads have been addressed in the present method by projecting the (x, y,ψ)-path onto the centerline of the corresponding lane, with thecenterline position and heading computed using a road geometry mappinglibrary. Where appropriate, the present disclosure indicates how thestraight-road assumption would be generalized to the non-straight roadcase.

Desired velocities ({dot over (x)}^(des), {dot over (y)}^(des)) arecomputed from (v^(des)ψ^(des)) using (1). The values (x^(des), y^(des),v^(des), ψ^(des)) therefore define X_(F)(t_(k)+T) at each update. In thestraight-road case, ψ^(des)=0 at every update. For the nominal update intask 1, the value for x^(des) is defined by extrapolatingx^(c)(t_(k−1)+T; t_(k−1)) by δ seconds, assuming that speed remainsconstant at v^(des) over the δ seconds. Thus, updates to (y^(des),v^(des)) completely define X_(F)(t_(k)+T) at each update.

There are a few cases to consider with defining (y^(des), v^(des)) ateach task 1 update. If no lane change occurs, then y^(des) is kept atits previous value. If a lane change occurs, then y^(des) is incrementedby one lane width. Simulations in the present disclosure involve a lanechange only for a merging car, though in-lane cars could also changelanes in general during task 1 (nominal update) or task 3 (as part of aresolution). Also, nominal updates in v^(des) are possible in task 1.For simplicity in this disclosure, v^(des) is set equal to the previousvalue set during the update period (i.e., no nominal changes to v^(des)in task 1). Thus, if no conflict resolutions are required for a car,v^(des) will remain the same indefinitely.

2) Task 3: Conflict resolutions in task 3 necessarily adjust v^(des),altering the value set at the nominal update (task 1). When resolving aconflict, x^(des) is defined to be set distance behind the car in frontin most cases. The only exception is when the lane merger is firstintroduced as a task 1 nominal update to y^(des). If the optimizationproblem solved in task 1 for an initial lane merger results in aconflict behind a car already in the lane, an alternative optimizationproblem is solved that replaces the equality constraint onx^(c)(t_(k)+T; t_(k)) with an inequality constraint, as detailed inSection IV.

B. Reference Trajectories

The assumed trajectories {circumflex over (M)}_(i)(t_(k)) are defined inthe four-task execution logic details in Section IV. If move suppressionis on (γ_(ms)=1), the reference trajectories are initialized using theassumed trajectories asx ^(ref)(s;t _(k))={circumflex over (x)}(s;t _(k)), y ^(ref)(s;t_(k))={circumflex over (y)}(s;t _(k))  (9){dot over (x)} ^(ref)(s;t _(k))={circumflex over (v)}(s;t _(k))cos[{circumflex over (ψ)}(s;t _(k))], {dot over (y)} ^(ref)(s;t_(k))={circumflex over (v)}(s;t _(k))sin [{circumflex over (ψ)}(s;t_(k))]  (10)

For non-straight road geometries, the reference trajectories are nextmodified by projecting the initial trajectories onto the road'scenterline path (available from a mapping library), keeping the speedprofile the same as before. The projection modification has the effectof removing steady-state errors that can accumulate if no projection wasused (data not shown). For proprietary reasons, details regarding theprojection method are not provided here. Since the simulations shown inSection V are for lane-merging on a straight road, no projection isneeded.

If move suppression is off (γ_(ms)=0), the reference trajectories arecomputed assuming a straight-line path from initial to final values withconstant heading and acceleration or deceleration. Though this choice ofreference trajectories may not be dynamically feasible in general, theyinfluence the cost function only, and the optimized trajectories arealways dynamically feasible.

III. Numerical Methods

This section shows how the OCP is time-discretized and numericallysolved. A key feature of the OCP defined in the previous section is thatthe discretized problem is a quadratic-programming (QP) problem, whichcan be solved using a QP-solver. With positive weights on each term inthe cost function, the present QP-problem has a unique global minimizeras its solution. In a non-limiting example, Matlab's solver quadprog.m(with the active-set algorithm) is used to solve the QP problem. Beforereviewing the methods, a nomenclature table (Table 3) is provided todefined relevant variables.

TABLE 3 Variable Definition Γ(k) B-spline coefficients that parameterizethe discretized and optimized trajectories for update t_(k). ζ(k) ∈Breakpoint time discretization vector defined as  

 ^(n) ^(b) ζ(k) = [ζ₁, ζ₂, . . . , ζ_(n) _(b) ], with ζ₁ = t_(k) andζ_(n) _(b) = t_(k) +T. n_(b) is the number of breakpoints, with n_(b) −1 polynomial pieces. τ(k) ∈ Time discretization for constraintenforcement and cost  

 ^(n) ^(e) evaluation τ(k) = [τ₁, τ₂, . . . , τ_(n) _(e) ], with τ₁ =t_(k) and T_(n) _(e) = t_(k) + T. n_(e) is the number of enforcementpoints, with n_(e) ≥ 2n_(b). Ξ(k) Discretized and optimized trajectories(termed “flat outputs”) defined at breakpoints ζ(k) for update t_(k)(initial guess is Ξ₀ (k)). κ Spline order (e.g., a₂t² + a₁t + a₀ isorder 3, with 3 coefficients) r Repetition number (multiplicity) of eachbreakpoint. m Smoothness of spline at breakpoints (m = κ − r). Spline isC^(m−1) n_(c) Number of coefficients per output n_(c) = (n_(b) − 1)(κ −m) + m = (n_(b) − 1)r + m.

In the spline parameterization, each ζ₁ defines the breakpoint in timewhere two polynomial pieces are joined in the trajectory, and n_(b) isthe number of breakpoints. In the present formulation, the breakpointand enforcement time point vectors are linearly spaced between the startand end times of each RH planning period. The discretized optimalcontrol problem is parameterized using B-spline polynomials. One cansetup the problem to solve for the B-spline coefficients Γ_(i)(k) asdone in [14], [16]. Alternatively, one can setup the problem to solvedirectly for the trajectories defined at the B-spline breakpointsΞ_(i)(k), as done in [20]. The latter is more efficient (7 times fasterin based on observations), with equal accuracy, and so these results arepresented here.

There are n_(b)=6 breakpoints in (ζ₁, . . . , ζ_(nb)) the presentimplementation, which means there are five polynomial pieces (intervals)over the [0, 5] sec period, and one breakpoint every 1 second. Thevariables (x, y) are parameterized k^(th)-order B-spline polynomials. InMatlab, we set k=6 with interior breaks having multiplicity r=3. As aresult, the polynomial pieces are C^(k−r−1)=C² (i.e., m=3 smoothnessconditions are satisfied) at the interior breakpoints, and therefore C²over the [0, T] interval. The number of coefficients for each B-spline(for x and y) is equal to n, n_(c)=(n_(b)−1)(k−m)+m=18. There aren_(c)=51 enforcement points (τ₁, . . . , τ_(ne)) where the cost functionand constraints get evaluated and enforced, respectively.

The collocation matrix C_(cm) is defined in Matlab using the spcolfunction. The matrix C_(cm) has dimensions 3n_(e) H n_(c), and is a tallmatrix. Algebraically, the x^(c) trajectory and its derivatives satisfy

x ⁡ ( τ ⁡ ( k ) ) ⁢ = △ ⁢ [ x c ⁡ ( τ 1 ; t k ) x . c ⁡ ( τ 1 ; t k ) x ¨ c ⁡ (τ 1 ; t k ) x c ⁡ ( τ 2 ; t k ) ⋮ x ¨ c ⁡ ( τ n c ; t k ) ] = C cm ⁢ Γ x ⁡ (k ) ∈ 3 n e ; ⁢ and Γ^(x)(k) = C_(cm)^(⊥)x(τ(k)) ∈ ℝ^(n_(c)),where C_(cm) ^(⊥) is the pseudo-inverse of C_(cm). Coefficient vectorΓ^(y) is defined likewise by C_(cm), with y(τ(k))=C_(cm)Γ^(y)(k). The2n_(c)=36 coefficients are denoted Γ=(Γ^(x), Γ^(y)). The vectors x(τ(k)) and y(τ(k)) are the flat outputs at the enforcement points.Denote the (smaller) vectors of flat outputs at the breakpoints as

${{\Xi^{x}(k)}\overset{\bigtriangleup}{=}\begin{bmatrix}{x^{c}\left( {\zeta_{1};t_{k}} \right)} \\{{\overset{.}{x}}^{c}\left( {\zeta_{1};t_{k}} \right)} \\{{\overset{¨}{x}}^{c}\left( {\zeta_{1};t_{k}} \right)} \\{x^{c}\left( {\zeta_{2};t_{k}} \right)} \\\vdots \\{{\overset{¨}{x}}^{c}\left( {\zeta_{n_{b}};t_{k}} \right)}\end{bmatrix}},$with Ξ^(y)(k) denoting the comparable vector for y. The 2(3n_(b)=36)outputs are denoted Ξ=(Ξ^(x), Ξ^(y)). The collocation matrix C_(xm) isdefined to relate Ξ and Γ, asΞ^(x)(k)=C _(xm)Γ^(x)(k), and Γ^(x)(k)=C _(xm) ⁻¹Ξ_(i) ^(x)(k).  (11)

The collocation matrix C_(xm) has dimensions 3n_(b) H n_(c)=18 H 18, andis by design a square and invertible matrix [20]. The Ξ(k) variables arethe free variables to be optimized. Note that this is the same number offree variables to be solved for as when solving for the B-splinecoefficients Γ. By accessing the B-spline coefficients in (11), thevalues of the flat outputs can be accessed at the enforcement points.This is necessary for the move suppression constraints (5), and the costfunction (4), and is achieved by the relationx(τ(k))=C _(cm) C _(xm) ⁻¹Ξ_(i) ^(x)(k) and y(τ(k))=C _(cm) C _(xm)⁻¹Ξ_(i) ^(y)(k)  (12)

The initial and final constraints occur at breakpoints, and so nocollocation matrix is needed to access the states (this is not the casewhen the problem is parameterized in terms of Γ instead of Ξ. Forexample, the initial condition constraint on x^(c)(τ₁; τ_(k)) is posedin terms of the flat outputs as[1 0 . . . 0]Ξ^(x)(k)=x(t _(k))

Algebraic manipulation results in a flat output-parameterized QPproblem:

$\begin{matrix}{\min\limits_{\Xi}{\left( {\Xi - \Xi^{ref}} \right)^{T}{Q\left( {\Xi - \Xi^{ref}} \right)}}} & (13) \\{{{s.t.\; A_{eq}}\Xi} = b_{eq}} & (14) \\{{A_{ineq}\Xi} \leq b_{ineq}} & (15)\end{matrix}$

The 10 linear equality constraints (14) in the present OCP are (6) and(7) (and define A_(eq) and b_(eq)), and the 4n_(c) linear inequalityconstraints are (5) (and define (A_(ineq) and b_(ibeq)). In the costfunction, Ξ^(ref) parameterizes the reference values as defined by thecost function (4) and in Section II-B. Given the discretized referencetrajectories x^(ref)(τ(k)), the vector Ξ^(x,ref) is computed asΞ^(x,ref)=C_(xm)C_(cm) ^(⊥)x^(ref)(τ(k)), for example. The integratedcost (4) is discretized and becomes a summation, evaluating the terms atthe enforcement points. This means Q incorporates the matrixmultiplications in (12).

A numerical solution of the discretized OCP requires an initial guess,denoted Ξ₀. Nominal trajectories (corresponding to the assumedtrajectories {circumflex over (M)}) are used to generate the initialguess. Denoting the x nominal trajectories at update time t_(k) asx₀(τ(k)), the Ξ₀ ^(x)(k) is simply a sampled version of x₀(τ(k)) ifbreakpoints coincide with enforcement points, and a simple interpolationcan be used if breakpoints do not coincide with enforcement points. Theassumed trajectories {circumflex over (M)}(t_(k)) are also discretized,defined at τ(k), and can be computed from Ξ using (12) and converting tothe variables (x, y, ψ, v) using (2).

IV. Four-Task Logic

Details about each task in the execution logic are now provided. Duringupdate period [t_(k), t_(k+1)], solving an optimization problem for thefuture interval [t_(k+1), t_(k+1)+T] results in a solution Ξ_(i)(k+1)for vehicle i that can be implemented over the next update period. Forthe update period [t_(k), t_(k+1)], the tasks have the followingsequential steps:

-   1) Task 1—Nominal Updates.    -   a) Compute the initial states X(t_(k+1)) and desired states        X(t_(k+1)+T) (see Section II-A).    -   b) Test if the desired states include a lane change.        -   i) If the desired states do not include a lane change, keep            the move suppression flag ON (i.e., γ_(ms)=1), and define            the assumed trajectories {circumflex over (M)}_(i)(t_(k+1))            as the remainder of the trajectories computed during the            previous update, extended by δ seconds to end at the desired            states. In the case of y, for example, this is

$\begin{matrix}{{\hat{y}\left( {t;t_{k + 1}} \right)} = \left\{ \begin{matrix}{{y^{c}\left( {t;t_{k}} \right)},} & {{t\; \in \left\lbrack {t_{k + 1},{t_{k} + T}} \right\rbrack},} \\{y^{des},} & {t\; \in \left( {{t_{k} + T},{t_{k + 1} + T}} \right\rbrack}\end{matrix} \right.} & (16)\end{matrix}$

-   -   -   ii) If the desired states do include a lane change, turn the            move suppression flag OFF (i.e., γ_(ms)=0), and use            optimization to compute Ξ_(i)(k+1). The assumed trajectories            {circumflex over (M)}_(i)(t_(k+1)) are computed from            Ξ_(i)(k+1),

-   2) Task 2—Communication. Once task 1 is complete, each coordinating    car broadcasts {circumflex over (M)}_(i)(t_(k+1)), and receives    {circumflex over (M)}_(j)(t_(k+1)) for each car j in a prescribed    range.

-   3) Task 3—Conflict Detection and Resolution.    -   a) For each neighboring car j, check for a conflict. A conflict        is detected if the assumed trajectories, which have rectangular        safety margins around them, overlap at any time in the interval        [t_(k+1), t_(k+1)+T]. The function checkConflict.m used for        conflict checks is provided in Appendix A. Cars are checked in        serial order, sorted by car number.        -   i) If no conflict is detected, proceed to checking the next            neighboring car.        -   ii) If conflict is detected, compute conflict type=1, 11,            21, 22, 23, 24 or 3 (each defined in Section IV-A) and store            in a conflict log. If the conflict type (1 or 21 or 22)            warrants a resolution, turn the move suppression flag OFF            (i.e., γ_(ms)=0), then compute and store the change in            desired states X(t_(k+1)+T) that will provide a resolution.            Proceed to checking next neighboring car. NOTE: turning the            move suppression flag OFF is only done once.    -   b) Once all neighboring cars are checked for conflicts, if any        resolutions are required, use optimization to compute Ξ_(i)(k+1)        for the “most critical” conflict, defined as the conflict that        results in greatest loss of separation between the two cars. If        a type 22 conflict occurs, the optimization problem is modified,        as detailed in Section IV-A.

-   4) Task 4: If move suppression flag is still on (γ_(ms)=1), solve    the optimization problem. This is the case only if optimization was    not used in the nominal update (task 1) or to resolve a conflict    (task 3).    Details regarding how conflicts are typed, how desired states    X(t_(k+1)+T) are updated to provide a resolution for specific    conflicts, and how prior and ongoing conflicts are logged and    logically handled, are provided in the coming sections.

A. Details on Task 3 Conflict Detection and Resolution

If a conflict is detected and a resolution for i is required, then x_(i)^(des) and v_(i) ^(des) can change, or v_(i) ^(des) alone changes. Theconflict detection and resolution logic is designed to rundeterministically and generate the same results in every car locally, sothat no further communications are required to achieve conflictresolutions. A conflict between cars i and j is detected using thecheckConflict.m function provided in Appendix A. The rectangular shapeassociated with each car's avoidance boundary has width equal toc_(W)+γε_(y)+2Δ_(y) and length c_(L)+γε_(x)+2Δ_(x), where (c_(W), c_(L))are the car width and length dimensions, γ=1 when one car isnon-coordinating and γ=2 when both are coordinating. The larger γ forboth cars coordinating is due to the increased position flexibilitypermitted by the move suppression constraints. The parameters (Δ_(x),Δ_(y)) define nominal avoidance boundaries. The logic in checkConflict.m(Appendix A) takes the global position and heading of a pair of cars,and checks if their rectangular shapes overlap. Since the rectangles canhave arbitrary relative heading, this function is already applicable tonon-straight road geometries.

The checkConflict.m function is called within a for-loop and evaluatedsequentially at each breakpoint {τ₁, τ₂, . . . , τ_(nb)}. If a conflictis detected, the first breakpoint that registers a conflict defines the“first loss-of-separation time,” and the breakpoint that corresponds tothe largest loss of separation during the planning horizon defines the“maximum loss-of-separation time.” The logic then proceeds with typingthe conflict, as detailed below. There are three main categories inenumerating pair-wise (i and j) conflict types for car i:

-   -   1) When a front/rear conflict arises in the same lane,        satisfying        |ŷ _(i)(t _(k) ;t _(k+1))−ŷ _(j)(t;t _(k+1))|≤η,∀t∈[_(k+1) ,t        _(k+1) T],  (17)        -   (η is a proprietary value) there are two types:            -   Type 1: If {circumflex over (x)}_(i)(t_(k+1);                t_(k+1))<{circumflex over (x)}_(j)(t_(k+1); t_(k+1)),                signaling that car i is behind car j. In this case, car                i logs the conflict and a resolution based on the                adaptive v^(des) update rule (alternative update rules                have been tested, and are possible):

$\begin{matrix}{{v_{i}^{des} = {v_{j}^{des} + {\beta\left\{ {{{\hat{v}}_{j}\left( {t_{k + 1};t_{k + 1}} \right)} - {{\hat{v}}_{i}\left( {t_{k + 1};t_{k + 1}} \right)}} \right\}} + {\alpha{\min\limits_{t}{g_{y}\left( {t,i,j} \right)}}}}},} & (18)\end{matrix}$

-   -   -   where            g _(y)(t,i,j)=|ŷ _(i)(t;t _(k+1))−ŷ _(j)(t;t _(k+1))|−(c            _(W)+γϵ_(y)+2Δy).        -   The desired position behind the car is            x _(i) ^(des) ={circumflex over (x)} _(j)(t _(k+1) +T;t            _(k+1))−[c _(L)+γϵ_(x)+2Δ_(x)],  (19)        -   using γ=2 if car j is coordinating, γ=1 if non-coordinating.            While this adaptation may initially resolve the conflict,            the conflict can re-occur later, since the adaptation is            attempting to space the cars optimally, i.e., such that            there is no wasted space and the boundaries of desired            separation are tangent to one another.            -   Type 11: If car i is ahead of car j, car i only logs the                conflict, but does not change v^(des). In this case, the                conflict must be resolved by car j.        -   This front/rear conflict is typically resolved by the next            update period. Nonetheless, type 1 and 11 conflicts are kept            in the log and (18)-(19) is indefinitely implemented for the            following car, unless the leading car changes lanes or a new            conflict arises (e.g., a car merges between car i and car j,            as considered in the simulations).

    -   2) If a conflict does not satisfy (17) for all tε[t_(k+1),        t_(k+1)+T], but does satisfy (17) at t=t_(k+1)+T, (that is, the        cars start in different lanes but end in conflict in the same        lane) there are four possibilities (labeled type 2x, with x=123        or 4):        -   Type 21: Car i is in the lane approaching a merging car j            too closely from behind. As with type 1, the (18)-(19)            adaptation is stored in the log as the resolution.        -   Type 22: Car i is merging into a lane and approaching an            in-lane car j too closely from behind. The resolution must            change the merging maneuver to not run into car j from            behind. This is the only conflict type that utilizes an            alternative optimization problem to compute resolution.            Constraint parameter updates (18)-(19) are used, but the            equality constraint on x^(c)(t_(k)+T; t_(k)) is changed from            x^(c)(t_(k)+T; t_(k))=x_(i) ^(des) to x^(c)(t_(k)+T;            t_(k))≤x_(i) ^(des). When this conflict occurs, it is by            definition the “most critical” conflict for the merging car.            The modified optimization problem is solved at the end of            task 3 in this case.        -   Type 23: Car i is in the lane and ahead of merging car j.            There is no resolution stored in the log, and car j is            responsible for resolving this conflict.        -   Type 24: Car i is merging ahead of in-lane car j, which is            approaching car i too closely from behind. As with type 23,            there is no resolution stored in the log, and car j is            responsible for resolving this conflict.

    -   3) If a conflict does not fit any of the above criteria, it is        given Type 3—this includes all unclassified conflicts. Future        work will explore detection and classification of other        conflicts.

In the merging scenario considered in the next section, type 3 conflictsare never encountered, while all other conflict types (six: 1, 11, 21,22, 23, 24) do occur. Type 3 conflicts have been observed innon-straight road situations.

V. Simulation of a Six-Car Merging Scenario

In the six-car scenario, four coordinating cars (numbered 1, 2, 3, 4)interact with two non-coordinating cars (numbered −1, −2). The initialconditions, and corresponding lane, for each car at the start of thesimulation is shown in Table 4 below.

TABLE 4 Initial Condition Lane Car No. (x(0), y(0), ψ(0), v(0))(Merging, Left, Right) 1 (coord) (−95, 1.75, 0, 25) Merging 2 (word)(−110, −1.75, 0, 25) Left 3 (coord) (−140, −1.75, 0, 27) Left 4 (coord)(−170, −1.75, 0, 27) Left −1 (non-coord) (−80, −1.75, 0, 25) Left −2(non-coord) (−50, −5.25, 0, 20) Right

Non-coordinating cars travel at constant speed without changing lanes.The objective is for Car 1 to merge into the left freeway lane, and Cars1-4 to avoid conflicts with each other and with non-coordinating cars.Challenging initial conditions were chosen to cause a chain of conflictswithin the left-hand lane. An extended version of the logic permitscoordinating cars to change lanes to avoid conflicts while maintaining adesired speed, under specific circumstances. The purpose of thenon-coordinating Car −2 is, essentially, to block this from happening,so that left-lane coordinating cars are forced to slow down to avoidconflicts. The details of this extended logic are not provided here.

The positions of the six cars at initial time t₀=0 are shown in FIG. 4A.The cars are represented by blue rectangles. The black boundarysurrounding each car represents the avoidance boundary parameterized by(Δ_(x), Δ_(y)), and the added white boundary around coordinating Cars1-4 represents the added margin afforded by move suppression parameters(ε_(x), ε_(y)). The positions are shown at time 3.4 sec in FIG. 4B.Observe the color change in the boundaries of coordinating Cars 2 and 3.This was done to signal a conflict at that time. The conflict occursbecause Car 3 is going 2.0 m/sec faster behind Car 2. The four-tasklogic detects and resolves conflicts that may occur at any time duringthe 5-second planning horizon; thus, conflicts can be resolved with novisible color change, since only the first 0.5 sec of each 5 sec windoware implemented. Conflicts that do include the implemented portion ofthe RH planning period will cause the boundary color change. The colorred is used to signal a conflict with one car, and the color yellowsignals a conflict with two cars simultaneously.

The position of the six cars at time 47 sec is shown in FIG. 4C. Thelane merging by Car 1 is now progressing. At this time, there is adetected conflict between Car 1 and non-coordinating Car −1, although itis not yet observable by any color change. This is because the conflicthappens 1.2 seconds into the RH planning period, i.e., after the RHupdate period duration, but before the end of the RH planning period forCar 1. The conflict between Cars 1 and 2 happens from the start of theplanning period, and so is visible from the boundary color change. Dueto the conflict between Car 1 and non-coordinating Car −1, Car 1 isslowing down while changing lanes, making use of an alternativeoptimization defined in task 3. In fact, Car 1 continues to slow downuntil time t≈8 seconds to resolve the conflict with Car −1. The timehistory of the speeds v, for all coordinating cars is shown in FIG. 5.

The position of the six cars at time 5 sec is shown in FIG. 4D. This isthe first time that the conflict between Cars 1 and −1 occurs within theRH update period, and so results in the color change in the boundary ofCar 1. The position of the six cars at time 8.7 sec is shown in FIG. 4E.Although conflicts exist at this time, the black boundaries do not (andwill not) overlap. At time t=18.5 seconds, there are no conflictspresent between any cars. FIG. 4F shows the cars at the end time of thesimulation, with no conflicts present. Use of (18)-(19) can causeeventual re-activation of type 1-type 11 conflicts, though this does notoccur within the simulation time shown. For the remainder of thissection, the progress of the four-task logic execution during thesimulated merging scenario is highlighted at specific RH update periods.

During RHC iteration 1 (0.0 to 0.5 sec), an in-lane conflict betweenCars 2 and 3 is first detected (type 11 for Car 2, and type 1 for Car3). Car 3 implements the adaptive update rule (18), and at RHC iteration2, the conflict is gone. When the difference in speed between cars inthis conflict scenario is larger, the conflict can persist for more thanone update period before going away. In this case, Cars 2 and 3 haveonly a 2 m/s speed difference, and start far enough apart initially toprevent an egregious conflict.

During RHC iteration 2 (0.5 to 1.0 sec), Car 3 has an ongoing type 1conflict with Car 2, though the conflict is no longer active. Car 2removes the type 11 conflict from the log, since it is no longer active,while Car 3 keeps the type 1 conflict in the log, and continues toimplement the adaptive v^(des) update rule (18). Car 3 also has a newtype 11 conflict with Car 4, and Car 4 performs a resolution to slowdown behind Car 3. By RHC iteration 3, since by (18) Car 3 is attemptingto maintain the minimum safe separation distance, the conflict with Car2 is re-activated. Since Car 2 removed the prior type 11 conflict withCar 3, it is treated as a new type 11 active conflict. Since Car 3 keptthe conflict in the log, it is treated as a pre-existing type 1 conflictwith Car 2 that is reactivated. Alternative methods of conflict logmanagement are possible, of course.

Initially, Cars 3 and 4 have the same speed. When Car 3 slows down toresolve the conflict with Car 2, it creates a conflict with Car 4 at thenext RHC iteration. As with the Car 2-Car 3 conflict, the Car 3-Car 4conflict requires Car 4 to slow down. By the next RHC iteration, thisconflict is gone, and Car 3 removes the conflict (type 11) from its log,while Car 4 keeps the conflict (type 1) to continue to implement (18).

During RHC iteration 8 (3.5 to 4.0 sec), Car 1 computes a nominallane-changing maneuver, and two new conflicts arise: A type 24 conflictwith Car 2 (which requires Car 2 to resolve, and it does), and a type 22conflict with non-coordinating Car −1. Resolving task 22 requires Car 1to merge while slowing down behind Car −1, for which an alternativeoptimization problem is run. The problem is like the OCP, except thereare no move-suppression constraints, and x(t_(k)+T) is bounded ininequality constraints, instead of being set equal to x^(des) in anequality constraint. The need for Car 1 to merge while slowing downbehind Car −1 persists until RHC iteration 18, at which time theresolved conflict is removed from the log.

During RHC iteration 31(15.0 to 15.5 sec), Car 1 has an ongoing conflictof type 24 with Car 2, which was initially detected at time 4. At thistime of detection, this conflict was type 21 for Car 2, since Car 2 wasapproaching merging Car 1 too closely from behind, in the left lane. Attime 12, the type 21 conflict for Car 2 was converted to type 1 since issatisfied the condition (17). Also, at time 12, the type 24 conflict forCar 1 was converted to type 11. Type 11, 23 and 24 conflicts are removedfrom a log if the conflict becomes in-active at any RH update.

During the final RHC iteration 60 (29.5 to 30.0 sec), Cars 1-4 show noactive conflicts, while Cars 2-4 have ongoing resolution of the type 1conflicts with the cars ahead of them. The adaptive update rule (18) forv^(des) is being implemented in all three cases. Note that the rule canresult in the conflict becoming transiently active again, if theinter-vehicle distance shrinks below the desired separation ofc_(L)+γε_(χ)+2Δ_(χ). In any case, the vehicles are observed to convergeto the common separation distance and speed 25 m/s.

The total computation time to serially compute the four-task logic foreach of the 4 cars, for all 60 receding horizon updates, was 8.44seconds. Dividing the total time by the number of cars and updateperiods, the four-task execution runtime per vehicle and per updateperiod was ˜35 milliseconds for this simulation example. The simulationswere run on a Sony VAIO laptop (Intel Core Duo CPU, T7500 at 2.2 GHz,with 2 GB RAM). The demonstrated speed of the logic andoptimization-based control calculations suggests that implementations onreal vehicles, with dedicated hardware, is certainly feasible.Additionally, most of update period can be dedicated to transmitting andreceiving data (Task 2 of FIG. 1) in real implementations. More than 90%of the 0.5 sec would available for Task 2 in the simulation example.

VI. Realistic Large-Scale Simulation

This section details the incorporation of the partially-synchronousfour-task strategy into a larger-scale merging scenario. This scenariomodels a representative merge on the Japanese Tomei Expressway, whichruns between Tokyo and Nagoya. The scenario has one short (90 m) mergingzone with a single merge lane and two highway lanes, which are termedcruising (i.e. slow lane) and passing (i.e. fast lane) (see FIG. 6).

In addition to the optimization-based maneuvering and logic-basedconflict avoidance of the four-task strategy, this simulation expandsthe cooperation between vehicles to include discrete negotiation betweenvehicles to align merging vehicles with gaps in the highway flow. Thenegotiation between vehicles leverages communication to proactivelyreduce the number and severity of conflicts that would subsequentlyrequire resolution if vehicles only reacted to the assumed trajectories,{circumflex over (M)}, of neighboring vehicles at the time of themerging lane change. The negotiation between vehicles aligns arrivaltimes, speeds, and relative positions at the point of the merging lanechange. The negotiation logic realizes this alignment by modifying theend points of the nominal trajectories, x₀, given in task 1 of theoptimization-based maneuver planning.

Besides the negotiation logic, the simulations also utilize the roadgeometry mapping library mentioned earlier to update nominal and computereference trajectories such that the vehicles follow the geometry of theJapanese highway. Furthermore, each vehicle's computed trajectory,χ^(c), which is in a global coordinate frame, is converted to thebody-fixed control inputs of longitudinal acceleration and steeringwheel angle, which induces a yaw rate.

Different flow rates (see Table 5) and inter-vehicle communication(i.e., V2V) penetration percentages (0%, 5%, 10%, 20%, 50%, 75%, 100%)are used in the large-scale simulations. The combinations of light flowrates (e.g., 450 veh/hr implies 1 veh/8 s arrival rate) and heavy flowrates (e.g., 1800 veh/hr implies 1 veh/2 s arrival rates) were used tochallenge the negotiation and four-task logic.

TABLE 5 Traffic Flow Pattern 1 2 3 4 Merging Lane  900 veh/hr  450veh/hr  900 veh/hr  900 veh/hr Cruising Lane  900 veh/hr  450 veh/hr1350 veh/hr 1800 veh/hr Passing Lane 1800 veh/hr 1800 veh/hr 1350 veh/hr 900 veh/hr

FIG. 6 shows snapshots of a particular merging vehicle that negotiates agap in front of a highway vehicle. The figure shows the three lane types(passing, cruising and merging) and the merging zone during thesimulation.

The following are some qualitative observations from these simulations.

-   -   A slight (3%) increase in the average arrival speed of merging        vehicles was observed for those that incorporated a negotiated        gap in the highway flow.    -   Significant traffic flow improvement requires greater than 50%        V2V penetration.    -   With sufficient V2V penetration, the negotiation allows for        better load balancing on the highway lanes leaving the merge        zone.    -   Negotiation harmonizes and slightly (3-5%, depending on V2V        penetration percentage) increases the average speeds through the        merge zone.

To clarify the significance of these large-scale simulations, it shouldbe noted that the heavy flow rates do not cause any loss of liveness tothe simulation and that each cooperative vehicle executes the four-tasklogic within every 0.5 second update period of simulation time.Moreover, the optimization-based maneuver planning is performed byvehicles regardless of their position on the road and their surroundingvehicles. The method's generality allows the vehicles to path plan underall scenarios, such as car-following, lane-changing, and open road. Inthe case of merging, some vehicles will modify their nominaltrajectories to assist or complete a highway merge, but the generalityof the methods means that all cooperative vehicles continually performthe four-task logic, and thereby ensure conflict-free driving anywherealong the roadway.

VII. Discussion of Hardware Controllers

FIG. 7 schematically illustrates a processing system in accordance withthis disclosure. Such a processing system is provided in each vehicle ofa platoon. However, it is should be appreciated that an identicalprocessing system in each vehicle is not necessary. Yet, providing eachvehicle with the processing system allows the vehicles to process inparallel in accordance with this disclosure.

The processing system can be implemented using a microprocessor or itsequivalent, such as a central processing unit (CPU) or at least oneapplication specific processor ASP (not shown). The microprocessorutilizes a computer readable storage medium, such as a memory (e.g.,ROM, EPROM, EEPROM, flash memory, static memory, DRAM, SDRAM, and theirequivalents), configured to control the microprocessor to perform and/orcontrol the processes and systems of this disclosure, including executedall or part of the equations and algorithms described herein in serialor parallel. Other storage mediums can be controlled via a controller,such as a disk controller, which can controls a hard disk drive oroptical disk drive.

The microprocessor or aspects thereof, in an alternate embodiment, caninclude or exclusively include a logic device for augmenting or fullyimplementing the algorithms and processes presented in this disclosure.Such a logic device includes, but is not limited to, anapplication-specific integrated circuit (ASIC), a field programmablegate array (FPGA), a generic-array of logic (GAL), and theirequivalents. The microprocessor can be a separate device or a singleprocessing mechanism. Further, this disclosure can benefit from parallelprocessing capabilities of a multi-cored CPU.

In another aspect, results of processing in accordance with thisdisclosure can be displayed via a display controller to a monitor (e.g.,allowing a driver to perceive a status of cooperative vehicle control orto confirm commands from a lead vehicle). The display controller wouldthen preferably include at least one graphic processing unit forimproved computational efficiency. Additionally, an I/O (input/output)interface is provided for inputting sensor data from Sensors 1, 2 . . .N, which collect data relating to vehicle positioning (either, own orother vehicle positioning).

Further, as to other input devices, the same can be connected to the I/Ointerface as a peripheral. For example, a keyboard or a pointing device(not shown) for controlling parameters of the various processes andalgorithms of this disclosure can be connected to the I/O interface toprovide additional functionality and configuration options, or controldisplay characteristics. Moreover, the monitor can be provided with atouch-sensitive interface to a command/instruction interface.

The above-noted components can be coupled to a network, as shown in FIG.7, such as the Internet or a local intranet, via a network interface forthe transmission or reception of data, including controllableparameters. The network can also be a vehicle-centric network such as avehicle local area network. In such an implementation, vehicle pathprediction can be routed by packets to automated vehicle equipment tocontrol steering, throttle and braking for purposes of cooperativevehicle control and collision avoidance via the vehicle local areanetwork. That is, the control path for the cooperative vehicle can beexecuted by transmitting appropriate commands and instructions to theautomated vehicle equipment. Other implementations include safetywarnings and driver assistance. Also, a central BUS is provided toconnect the above hardware components together and provides at least onepath for digital communication there between.

A coordinating vehicle can also be connected to other coordinatingvehicles via the network, either via the Internet or a proprietaryprivate network. Also, vehicle communications can also be performed byradio communications which do not rely specifically on an Internet-basednetwork. Such communications can rely on GSM, CDMA or LTE-basedcommunications, and can involve relaying via a base station or otherintermediary device. Otherwise, communication can be performed directlyby various methods capable of transferring data between devices.

As shown in FIG. 7, a coordinating vehicle may also detect the presenceof a non-coordinating vehicle via peripheral sensors, such as radartransceivers. In a non-limiting example, the sensors are configured todetermine relative location and actual speed information of surroundingnon-coordinating vehicles within a detection range. Based on thedetermined location and speed information, the processor is configuredto calculate trajectory information corresponding to each detectednon-coordinating vehicle. Accordingly, conflicts with non-coordinatingvehicles are detected and resolved by the processing system based on thetrajectory information and the above-described logic and the followingexemplary algorithm, with the exception of communication betweencoordinating and non-coordinating vehicles.

FIG. 8 shows an algorithm 800 implementing one embodiment of thisdisclosure in accordance with the four-task logic discussed above, whichinvolves the processing of at least one processing system, such as thatshown in FIG. 7. FIG. 8 involves steps which may be performed by asingle controller or by a plurality of controllers operating in parallelor in a partially sequential manner, in accordance with the descriptionsprovided above.

Referring to exemplary algorithm 800, a first coordinating vehicle whichincludes the above-described processing system first calculates anassumed trajectory (S802). Next, the first coordinating vehicleexchanges trajectory messages with other coordinating vehicles which arewithin a communication range (S804). Based on the calculated assumedtrajectory and the received trajectory messages, the first coordinatingvehicle determines if a conflict between coordinating vehicles willoccur (S806). If a conflict is detected (S808), the terminal constraintsof the first coordinating vehicle's optimal control problem (OCP) areadjusted (S810) and an optimized trajectory is calculated such that theconflict is resolved (S812). If no conflict is detected at step S808,the first coordinating vehicle will calculate an optimized trajectorywithout adjusting the optimal control problem terminal constraints. Theprocessing system can be configured such that processing, such as inexemplary algorithm 800, occurs recursively over subsequent updateintervals.

Any processes, descriptions or blocks in flow charts or functional blockdiagrams should be understood as representing modules, segments,portions of code which include one or more executable instructions forimplementing specific logical functions or steps in theprocesses/algorithms described herein, and alternate implementations areincluded within the scope of the exemplary embodiments of thisdisclosure in which functions may be executed out of order from thatshown or discussed, including substantially concurrently or in reverseorder, depending upon the functionality involved.

Moreover, as will be recognized by a person skilled in the art withaccess to the teachings of this disclosure, several combinations andmodifications of the aspects of this disclosure can be envisaged withoutleaving the scope of this disclosure. Thus, numerous modifications andvariations of this disclosure are possible in light of the aboveteachings, and it is therefore to be understood that within the scope ofthe appended claims, this disclosure may be practiced otherwise than asspecifically described herein.

VIII. Conclusions and Extensions

This disclosure considers the problem of automated freeway merging. Themethod presented to address this problem incorporates receding horizoncontrol as a lower-level control method, combined with a higher-levellogic for management of lane changing and collision avoidanceobjectives. The method is distributed with partially-synchronousexecution, and relies on the high-level logic (rather than theoptimization algorithm) to solve conflicts as they arise. It is thusapplicable to traffic flows of arbitrary size, including under realisticconditions. The local optimization problems are also entirely decoupled;thus, feasibility of each problem does not depend on the performance ofother vehicles. Additionally, the optimization problem when discretizedbecomes a quadratic programming problem, for which global minimizers canbe computed in real-time with great efficiency [25]. The method wasdemonstrated in detail in a 6-car simulation, and more coarsely (showingtrends) in larger-scale simulations that reflect realistic mergingscenarios on Japanese freeways.

In the present disclosure, cars are either “coordinating” or“non-coordinating,” with coordinating cars running the method derivedand non-coordinating cars proceeding with predictable dynamics. Thus,the results shown rely on the assumption that the short-term future planof non-coordinating cars is predictable without error by eachcoordinating car. With advances in vehicle-2-vehicle (V2V) technology,real-time knowledge of the state of non-coordinating cars is a realisticassumption, but consideration of uncertainty in the state and thepredicted short-term plan for such cars must be addressed forimplementations.

At present, communication between cars is assumed to be lossless. Priorto implementation, communication failures between cars must also beconsidered. RHC has the advantage of having a look ahead policy, so thatcommunication loss can be handled in principle by continuing to use themost recently received policy. In the context of this project, policiesare the assumed trajectories. An obvious issue is that, if communicationis lost and this is unknown to the transmitting car, that car maycontinue with modifying its assumed trajectory (by resolving a conflictwith a different car, say), and implement a resolution that is notconflict-free with the car that lost communication. Most worst-casescenarios may or may not be possible, depending on the worst-casecommunication failures. Failures that last over multiple update periods,for example, are essentially impossible to resolve in general. Iffailures are limited to single update periods, contingencies can bedeveloped to deal with communication loss. For example, the lost-car canbe given priority in its maneuver selection, if the loss is unknown tothat car. An easier case is when cars are aware of the loss, in whichcase contingencies that are mutual to both parties can be developed.

The four-task strategy presented here separates the optimization problemfrom the handling of collision avoidance. This is a distinct advantagecompared to approaches in the literature that include collisionavoidance constraints directly in the optimization problem, whichincreases the computation time drastically.

APPENDIX

A. Conflict checking function in Matlab

The following Matlab function checkConflict.m was created based on thelogic in [2]. Given (x₁, y₁, ψ₁) and (x₂, y₂, ψ₂) for two rectangles(presumed coordinating cars here), the function returns a 1 if there isoverlap (a conflict) and 0 otherwise. The coordinate frame here isconsistent with the configuration shown in FIG. 2: x-positive verticaland up, y-positive horizontal and left, with ψ-positivecounter-clockwise and zero along the positive x-axis.

-   -   Start function:        function flag=checkConflict(x1,y1,psi1,x2,y2,psi2,PARAMS)    -   Within the PARAMS structure, the following parameters are        defined: carW (car width); cart (car length); xdev, ydev (move        suppression margins ϵ_(x), ϵ_(y)); and xmargin, ymargin        (conflict avoidance margins Δ_(x), Δ_(y), defined in Section        IV-A).    -   Next, create rectangle structures, with variables that are        assigned the coordinates, angles and dimensions of the cars:        a1=carL/2+xmargin+xdev; b1=carW/2+ymargin+ydev; a2=a1; b2=b1;        rect1=[ ]; rect2=[ ];        rect1.S=[a1;b1]; rect2.S=[a2;b2]; % half-boundary dimensions        rect1.center=[x1;y1]; rect1.angle=psi1;        rect2.center=[x2;y2]; rect2.angle=psi2;    -   Shift rect2 (associated with car 2) to the origin:        rect2.center=rect2.center−rect1.center;    -   Rotate plane (i.e., rotate the vector to translated rect 2) to        make rect2 x-axis aligned        ang=rect2.angle;        W=[cos(ang)sin(ang);−sin(ang)cos(ang)];        rect2.center=W*rect2.center;    -   Compute extreme vertices of translated, axis-aligned rect2        BL=rect2.center−rect2.S; % bottom-left        TR=rect2.center+rect2.S; % top-right    -   Calculate vertices of rotated rect1        sin a=sin(rect1.angle−rect2.angle);        cos a=cos(rect1.angle−rect2.angle);        W=[cos a−sin a; sin a cos a];        A=W*rect1.S; B=W*[−rect1.S(1);rect1.S(2)]; t=sin a*cos a;    -   Verify that A is vertical min/max, B is horizontal min/max    -   if t<0        Ap=B; B=A; A=Ap;    -   end    -   Verify that B is horizontal minimum (leftest-vertex) of rotated        rect 1 (and therefore has a negative x-value)    -   if sin a<0, B=−B; end    -   If (rotated rect 1 not in horizontal range of        (translated/axis-aligned) rect 2, then collision is impossible.    -   if (B(1)<TR(1)∥B(1)>−BL(1))        -   flag=0; return    -   end    -   If rotated r1 axis aligned, vertical min/max are easy to get.    -   if t==0        ext1=A(2); ext2=−ext1;    -   else        x=BL(1)−A(1); a=TR(1)−A(1); ext1=A(2);        -   % If the first vertical min/max isn't in (BL.x, TR.x), then            find the vertical min/max on BL.x or on    -   TR.x    -   if a*x>0    -   dx=A(1);    -   if x<0        dx=dx−B(1);        ext1=ext1−B(2);        x=a;    -   else        dx=dx+B(1);        ext1=ext1+B(2);    -   end        ext1=ext1*x/dc+A(2);    -   end        x=BL(1)+A(1); a=TR(1)+A(1); ext2=−A(2);    -   % if second vertical min/max isn't in (BL.x, Tr.x), then find        vertical min/max on BL.x or on TR.x    -   if a*x>0, dx=−A(1);    -   if x>0        dx=dx−B(1); ext2=ext2−B(2); x=a;    -   else        dx=dx+B(1);ext2=ext2+B(2);    -   end        ext2=ext2*x/dx−A(2);    -   end    -   end    -   Check for collision    -   if (ext1<BL(2) && ext2<BL(2))∥(ext1>TR(2) && ext2>TR(2))        -   flag=0;    -   else        -   flag=1;    -   end        The function is simply adapted to the case when car 2 is        non-coordinating by reducing the size of a2 and b2 by xdev and        ydev (the move-suppression margins), respectively.

The invention claimed is:
 1. A method comprising: performing a firsttask including calculating an assumed trajectory for a firstcoordinating vehicle by solving an optimal control problem; and performa second task including detecting a conflict based on trajectoryinformation for a non-coordinating vehicle and the calculated assumedtrajectory using a first avoidance boundary of the first coordinatingvehicle and a second avoidance boundary of the non-coordinating vehicle,wherein when a conflict is detected, terminal state constraints in theoptimal control problem are adjusted and an optimized trajectory for thefirst coordinating vehicle is calculated with the adjusted constraintsin the optimal control problem such that the detected conflict isresolved, the optimal control problem includes cost terms including amove suppression (MS) term indicating an amount that the optimizedtrajectory may deviate from the assumed trajectory, and the methodfurther comprises controlling the first coordinating vehicle based uponat least one of the assumed trajectory and the optimized trajectory. 2.A controller for a first coordinating vehicle, the controllercomprising: a computer processor configured to: perform a first taskincluding calculating an assumed trajectory for the first coordinatingvehicle by solving an optimal control problem, and perform a second taskincluding detecting a conflict based on trajectory information for anon-coordinating vehicle and the calculated assumed trajectory using afirst avoidance boundary of the first coordinating vehicle and a secondavoidance boundary of the non-coordinating vehicle, wherein when aconflict is detected, terminal state constraints in the optimal controlproblem are adjusted and an optimized trajectory for the firstcoordinating vehicle is calculated with the adjusted constraints in theoptimal control problem such that the detected conflict is resolved, theoptimal control problem includes cost terms including a move suppression(MS) term indicating an amount that the optimized trajectory may deviatefrom the assumed trajectory, and the computer processor is furtherconfigured to control the first coordinating vehicle based upon at leastone of the assumed trajectory and the optimized trajectory.
 3. Thecontroller according to claim 2, further comprising: a communicationterminal configured to receive trajectory messages from a plurality ofsecond coordinating vehicles in a communication range, the trajectorymessages including vehicle trajectory information for a predeterminedupdate interval, wherein the conflict is detected by determining, basedon the received trajectory information and the calculated assumedtrajectory, whether the first avoidance boundary of the firstcoordinating vehicle and a third avoidance boundary of any one of thesecond coordinating vehicles intersect during the update interval. 4.The controller according to claim 2, wherein: the terminal stateconstraints include a velocity term and a vehicle spacing term; and whena conflict is detected, the processor adjusts the velocity term and/orthe vehicle spacing term in the optimal control problem such that thedetected conflict is resolved.
 5. The controller according to claim 3,wherein during each of successive update intervals, the computerprocessor is further configured to: recursively detect conflicts betweenthe first coordinating vehicle and each of the second coordinatingvehicles that will occur during the update interval; and calculate theoptimized trajectory for each of the recursively detected conflicts. 6.The controller according to claim 2, wherein the computer processor isfurther configured to: classify the detected conflict based on apredetermined rule set; and adjust the terminal state constraints basedon the detected conflict classification.
 7. The controller according toclaim 2, wherein the assumed trajectory for the first coordinatingvehicle is calculated by solving the optimal control problem withterminal constraints modified by a high-level maneuver plan.
 8. Thecontroller according to claim 2, further comprising: a sensor configuredto detect a position and speed information for the non-coordinatingvehicle within a predetermined detection range, wherein the computerprocessor is configured to determine the trajectory information for thenon-coordinating vehicle based on the detected position and speedinformation.
 9. The controller according to claim 2, wherein theconflict is detected by determining, based on the trajectory informationfor the non-coordinating vehicle and the calculated assumed trajectory,whether the first avoidance boundary of the first coordinating vehicleand the second avoidance boundary of the non-coordinating vehicleintersect.
 10. The controller according to claim 5, wherein during eachof the successive update intervals, the communication terminal isfurther configured to: transmit the optimized trajectory to the secondcoordinating vehicles; and receive updated trajectory messages from thesecond coordinating vehicles.
 11. The controller according to claim 2,wherein the assumed trajectory for the first coordinating vehicle in acurrent update interval is initially set to the calculated optimizedtrajectory from an immediately preceding update interval.
 12. Thecontroller according to claim 2, wherein the assumed trajectory for thefirst coordinating vehicle in a current update interval is initiallyset, in the absence of a high-level maneuver plan, by extrapolating theoptimized trajectory from an immediately preceding update interval. 13.The controller according to claim 2, wherein the computer processor isfurther configured to, during each of successive update intervals,calculate the optimized trajectory for the detected conflict with anearliest loss-of-separation that requires action by the firstcoordinating vehicle.
 14. The controller according to claim 6, whereinthe conflict classification is based on a position of the firstcoordinating vehicle relative to a conflicting vehicle which isdetermined to be in conflict with the first coordinating vehicle. 15.The controller according to claim 2, wherein when a conflict isdetected, the MS term is set such that the amount from which theoptimized trajectory may deviate from the assumed trajectory isincreased.
 16. The controller according to claim 2, wherein the secondavoidance boundary is smaller in size than the first avoidance boundary.17. The controller according to claim 2, wherein the optimal controlproblem does not include at least one of (1) an avoidance constraintbetween the first coordinating vehicle and another vehicle and (2) anavoidance constraint between the first coordinating vehicle and a roadboundary.
 18. The controller according to claim 2, wherein the optimalcontrol problem does not include an avoidance constraint between thefirst coordinating vehicle and another vehicle and does not include anavoidance constraint between the first coordinating vehicle and a roadboundary.
 19. The controller according to claim 2, wherein the secondtask is discrete from the first task.
 20. A vehicle coordination systemcomprising a plurality of coordinating vehicles, each vehicle (i=1, 2,3, . . . , N) having a controller including: a communication terminalconfigured to receive trajectory messages from each vehicle, of theplurality of coordinating vehicles, in a communication range, thetrajectory messages including vehicle trajectory information for apredetermined update interval; and a computer processor configured to:perform a first task including calculating an assumed trajectory bysolving an optimal control problem, and perform a second task includingdetecting conflicts with corresponding vehicles based on the receivedtrajectory information, trajectory information for a non-coordinatingvehicle, and the calculated assumed trajectory using a first avoidanceboundary of a first coordinating vehicle, a second avoidance boundary ofa second coordinating vehicle, and a third avoidance boundary of thenon-coordinating vehicle, wherein when a conflict is detected, terminalstate constraints in the optimal control problem are adjusted and anoptimized trajectory is calculated with the adjusted constraints in theoptimal control problem such that the detected conflict is resolved, theoptimal control problem includes cost terms including a move suppression(MS) term indicating an amount that the optimized trajectory may deviatefrom the assumed trajectory, and the computer processor is furtherconfigured to control the first coordinating vehicle based upon at leastone of the assumed trajectory and the optimized trajectory.